<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>

<head>
<title>Table 5: Global Behavioral DML Attributes</title>
</head>

<body bgcolor="white">

<p align="left">
<b>Table 5: Global Behavioral DML Attributes</code></b> All attributes in this
table, if used, must appear as immediate subattributes of the
<code>bgpoptions</code> attribute, which itself is an immediate subattribute of
the top-level <code>Net</code> attribute.
</p>

<table align="center" border="1">

<tr>
<td align="left" valign="center">
<code>base_startup_wait</code>
</td>
<td align="left" valign="center">
A real-valued number indicating the minimum wait time, in seconds, at the
beginning of the simulation during which each BGP protocol session is inactive.
A typical use of this attribute is to force all BGP instances to wait in order
for other parts of the simulation to start up and reach some desirable state.
For example, one might want BGP to wait until OSPF has had a chance to
distribute information about the local network.  The default value for this
attribute is <code>5.0</code>.  See also the <code>startup_jitter_bound</code>
attribute.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>startup_jitter_bound</code>
</td>
<td align="left" valign="center">
A real-valued number indicating the upper bound on a range of time, in seconds,
to be used for adding jitter to the startup wait period on a per-BGP protocol
session basis.  The lower bound of the range is always 0.0.  Use 0.0 to imply
that no jitter should be used (this is the default value).  The actual jitter
applied to the startup wait period for each particular BGP instance is chosen
uniformly at random from the range.  Each BGP session will become active (BGP
Start commands will be issued) after <code>base_startup_wait</code> seconds
plus the amount of startup jitter time has elapsed in the simulation.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>auto_advertise</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not a BGP speaker should automatically
advertise the NLRI of its AS when it starts up.  The default is true.  This is
useful when the modeler wants to use basic inter-domain routing but does not
which to configure it in detail.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>proc_delay_model</code>
</td>
<td align="left" valign="center">
A string indicating the model being used for imposing CPU delay for BGP message
processing.  This is experimental, and the use of this option is not
recommended due to certain subtleties involved.  The default value is
<code>none</code>, indicating that no processing delay is associated with
processing BGP messages.  That is, all messages can be processed
instantaneously, causing no simulation time to pass.  The only other value
which can be used at this time is <code>uniform_random</code>, which indicates
that the processing delay for each update message will be chosen uniformly at
random from the range specified by the <code>min_proc_time</code> and
<code>max_proc_time</code> global attributes.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>min_proc_time</code>
</td>
<td align="left" valign="center">
A real-valued number indicating the minimum amount of CPU time to be imposed
for the processing of update messages.  This is experimental, and the use of
this option is not recommended due to certain subtleties involved.  See also
the <code>proc_delay_model</code> attribute.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>max_proc_time</code>
</td>
<td align="left" valign="center">
A real-valued number indicating the maximum amount of CPU time to be imposed
for the processing of update messages.  This is experimental, and the use of
this option is not recommended due to certain subtleties involved.  See also
the <code>proc_delay_model</code> attribute.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>global_ebgp_mrai</code>
</td>
<td align="left" valign="center">
An integer which sets the global default value for the MRAI, in seconds, to be
used with external neighbors.  If autoconfiguration is in use and this value is
specified, all MRAI timers for external BGP neighbors use it without exception.
If autoconfiguration is in use and this value is unspecified, all MRAI timers
use a system default value of 30 for eBGP neighbors without exception.  If
autoconfiguration is not in use and this value is specified, all eBGP MRAI
timers default to it, but they may be overridden on a per-BGP-neighbor basis in
the configuration file.  If autoconfiguration is not in use and this value is
unspecified, all eBGP MRAI timers must be specified in the configuration file
on a per-BGP-neighbor basis or an error will be flagged.  The value specified
by this attribute will be overridden if the MRAI is manually configured within
a particular BGP instance (using the <code>mrai</code> attribute).
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>global_ibgp_mrai</code>
</td>
<td align="left" valign="center">
An integer which sets the global default value for the MRAI, in seconds, to be
used with internal neighbors.  If autoconfiguration is in use and this value is
specified, all MRAI timers for internal BGP neighbors use it without exception.
If autoconfiguration is in use and this value is unspecified, all MRAI timers
use the system default value of 0 for iBGP neighbors without exception.  If
autoconfiguration is not in use and this value is specified, all iBGP MRAI
timers default to it, but they may be overridden on a per-BGP-neighbor basis in
the configuration file.  If autoconfiguration is not in use and this value is
unspecified, all iBGP MRAI timers must be specified in the configuration file
on a per-BGP-neighbor basis or an error will be flagged.  The value specified
by this attribute will be overridden if the MRAI is manually configured within
a particular BGP instance (using the <code>mrai</code> attribute).
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>global_hold_time</code>
</td>
<td align="left" valign="center">
An integer which sets the global default for the proposed Hold Timer value, in
seconds, to be used when negotiating peering sessions.  If autoconfiguration is
in use and this value is specified, all Hold Timers use it without exception.
If autoconfiguration is in use and this value is unspecified, all Hold Timers
use the system default value of 90 without exception.  If autoconfiguration is
not in use and this value is specified, all Hold Timers default to it, but they
may be overridden on a per-BGP-neighbor basis in the configuration file.  If
autoconfiguration is not in use and this value is unspecified, all Hold Timer
values must be specified in the configuration file on a per-BGP-neighbor basis
or an error will be flagged.  The value specified by this attribute will be
overridden if the Hold Time is manually configured within a particular BGP
instance (using the <code>hold_time</code> attribute).
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>global_keep_alive_time</code>
</td>
<td align="left" valign="center">
An integer which sets the global default for the Keep Alive timer value, in
seconds, to be used in peering sessions.  If autoconfiguration is in use and
this value is specified, all KeepAlive Timers use it without exception.  If
autoconfiguration is in use and this value is unspecified, all KeepAlive Timers
use the system default value of 30 without exception.  If autoconfiguration is
not in use and this value is specified, all KeepAlive Timers default to it, but
they may be overridden on a per-BGP-neighbor basis in the configuration file.
If autoconfiguration is not in use and this value is unspecified, all KeepAlive
Timer values must be specified in the configuration file on a per-BGP-neighbor
basis or an error will be flagged.  The value specified by this attribute will
be overridden if the Keep Alive time is manually configured within a particular
BGP instance (using the <code>keep_alive_time</code> attribute).
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>wrate</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not the MRAI timer should apply to withdrawals.
According to RFC 1771, the timer should not apply to withdrawals.  However,
some commercial implementations have been known to violate this part of the
specification.  The default value is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>split_horizon</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not to use the split horizon method of simple
loop detection.  The split horizon method prevents a BGP speaker from
advertising a route directly back to the peer from which it was received.  BGP
uses the split horizon method by default, but not full sender-side loop
detection (other than split horizon, receiver-side loop detection is used).  If
full sender-side loop detection is used (see the <code>ssld</code> global
attribute), then split horizon must be in use as well.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>ssld</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not to perform sender-side loop detection.
Sender-side loop detection is when the sender of an update message checks the
AS path of routes that it might send to check if it will cause a routing loop.
By default, split horizon is the only type of sender-side loop detection
performed, with receiver-side loop detection being the primary loop detection
method.  The default value of this attribute is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>rate_limit_by_dest</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not rate limiting should be applied on a
per-peer, per-destination basis.  The default is false, in which case rate
limiting is applied on a per-peer only basis, without regard to destination.
(In other words, per-peer only rate limiting only uses one timer per peer,
whereas per-peer, per-destination rate limiting requires one timer for every
peer-destination pair.  The latter is clearly more resource intensive.)  For
further information, refer to RFC 1771 section 9.2.3.1.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>route_flap_damp</code>
</td>
<td align="left" valign="center">
A boolean indicating whether to use route flap damping by default.  This can be
overridden in the configuration of individual BGP speakers when manual
configuration is used.  The default is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>punishLess</code>
</td>
<td align="left" valign="center">
A boolean indicating whether to punish path attribute changes by half the
normal penalty when route flap damping.  This attribute is ignored when route
flap damping is not in use.  The default is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>newRFD</code>
</td>
<td align="left" valign="center">
A boolean indicating whether to use the new algorithm when route flap damping.
This attribute is ignored when route flap damping is not in use.  The default
is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>always_run_dp</code>
</td>
<td align="left" valign="center">
A boolean indicating whether to always run the Decision Process when a new
route is inserted into an Adj-RIB-In.  The original RFC (1771) had complicated
rules for determining wether or not the Decision Process should be run.  Newer
drafts of the next version of the BGP specification (as of 2002-11-04) state
that the Decision Process should always be run when a new route is inserted
into an Adj-RIB-In.  The default is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>random_tiebreaking</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not the tie-breaking mechanism for route
preference, which normally reverts to BGP ID as a last resort, will instead
choose randomly between two options as a last resort.  The default is false.
For further information, refer to RFC 1771 section 9.1.2.1.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>fcfc</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not the tie-breaking mechanism for route
preference, which normally reverts to BGP ID as a last resort, will instead
choose the least recently learned (or first learned) route.  It is also known
as the first-come, first-chosen method of last-resort tie-breaking.  The
default value is false.  For further information, refer to RFC 1771 section
9.1.2.1.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>continuous_mrai_timers</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not continuously restarting MRAI timers should
be used.  The first time that an advertisement is to be sent to a particular
peer, the timer associated with that peer will be started, and the
advertisement will be put in the waiting list to be sent when the timer
expires.  From that point on, each time the MRAI timer expires it will be
immediately restarted.  The idea behind this option is that in the Internet,
there are so many updates constantly going around that the MRAI timers at most
routers are running continuously, being restarted every time they expire.  This
effect of continuously restarting MRAI timers can be achieved in simulation,
using this option, without the need all of the BGP updates that would otherwise
be required to cause the timer to continuously restart.  This option is
meaningful only when the MRAI timer is applied on a per-peer only basis.  The
default is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>randomized_mrai_timers</code>
</td>
<td align="left" valign="center">
A boolean indicating that when an MRAI timer is set for the first time when
using continuous MRAI timers, the value of the timer should be set for a random
time between 0 and the MRAI timer value.  Subsequent setting of the MRAI timer
will use the usual value (the full MRAI value).  This option is meaningful only
when the continuous MRAI timers option is in use.  The default is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>jitter_masoi</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not to jitter the Minimum AS Origination Timer.
Jitter is required for a conformant BGP implementation (see RFC1771:9.2.2.3).
The default is true.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>jitter_keepalive</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not to jitter Keep Alive Timers.  Jitter is
required for a conformant BGP implementation (see RFC1771:9.2.2.3).  The
default is true.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>jitter_mrai</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not to jitter Minimum Route Advertisement
Interval Timers.  Jitter is required for a conformant BGP implementation (see
RFC1771:9.2.2.3).  The default is true.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>auto_reconnect</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not a BGP speaker should automatically attempt
to reconnect when a peering session is lost.  If true, as soon as a peering
session is broken, BGP will re-enter the Connect state and begin an attempt to
establish a new transport session.  The default is true.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>auto_advertise</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not a BGP speaker should automatically
advertise its AS's network prefix to all neighbors.  It is true by default, in
which case each BGP speaker advertises a single prefix which encompasses the IP
block assigned to its AS.  If set to false, BGP speakers will not advertise any
routes.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>num_prefixes</code>
</td>
<td align="left" valign="center">
An integer indicating how many prefixes should be advertised per BGP speaker.
The value must be greater than 0, unless auto-advertisement is not in use, in
which case it must be 0.  The first prefix advertised by a BGP speaker is
always the speaker's AS's network prefix.  After that, phony addresses are
generated in such a way as to minimize the likelihood of conflicting addresses
in the network.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>note_last_sent</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not each BGP speaker should remember the last
advertisement sent for each destination (and per peer).  Doing so avoids a few
cases in which two consecutive identical advertisements could be sent.  The
overhead is fairly large and the occurrences of these cases fairly uncommon, so
the default value is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>ignore_repeat_ads</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not BGP should ignore an advertisement which is
identical to the previous advertisement received for the same destination from
the same peer (and having no withdrawal or session reset in between the two).
Ignoring such repeat advertisements is required by RFC 1771, and thus the
default is true.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>low_mrai_exp_priority</code>
</td>
<td align="left" valign="center">
A boolean indicating whether or not MRAI expiration events should have lower
priority than RecvUpdate events.  MRAI expiration events normally have higher
priority than incoming update messages; that is, when an MRAI timer expires,
that event is handled before any incoming update messages that may already be
waiting to be processed.  With low MRAI expiration priority, the two types of
events have equal priority.  The default value is false.
</td>
</tr>

</table>


<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>


</body>
</html>
